home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 7 / Apprentice-Release7.iso / Environments / Small Eiffel 0.4.8 / man / Eiffel.FAQ < prev    next >
Text File  |  1997-04-13  |  50KB  |  1,478 lines
  1. Archive-name: eiffel-faq
  2. Posting-Frequency: approximately monthly
  3. Last-modified: 04 Apr 1997
  4.  
  5. EIFFEL: FREQUENTLY ASKED QUESTIONS
  6. ----------------------------------
  7.  
  8. This question-and-answer list is posted monthly to the Usenet
  9. newsgroups comp.lang.eiffel, comp.answers and news.answers.
  10.  
  11. Please send corrections, additions and comments to Conrad Taylor
  12. (cwtaylor@tasc.com).
  13.  
  14. This information is abstracted and condensed from the posts of many
  15. contributors to comp.lang.eiffel, supplemented by information from
  16. vendors. No guarantees are made regarding its accuracy.
  17.  
  18. This compilation is by Conrad Taylor. Distribution over the Internet or
  19. by electronic mail is unrestricted. Other use requires my permission.
  20.  
  21. You can receive the latest copy by anonymous file transfer from:
  22.  
  23.    ftp://ftp.cm.cf.ac.uk/pub/eiffel/eiffel-faq
  24.    ftp://rtfm.mit.edu/pub/usenet/news.answers/eiffel-faq
  25.  
  26. or by sending an email message to mail-server@rtfm.mit.edu with this
  27. message body:
  28.  
  29.    send /pub/usenet/news.answers/eiffel-faq
  30.  
  31. ----------
  32.  
  33. CONTENTS
  34.  
  35. Changes since the last posting:
  36.  
  37. What's New:
  38.  
  39.    N01) Announce Visual Eiffel for Windows 95/NT
  40.    N02) ISE Eiffel 4 for Windows
  41.    N03) The long awaited "Object Oriented Software Construction 2ed" by
  42.     Bertrand Meyer
  43.  
  44. Frequently Asked Questions:
  45.  
  46.    Q01) What is Eiffel?
  47.    Q02) Where did Eiffel come from?
  48.    Q03) What Eiffel products are available?
  49.    Q04) Is Eiffel available for free or as shareware?
  50.    Q05) Is there an archive of the comp.lang.eiffel newsgroup?
  51.    Q06) What is Sather? How does it compare to Eiffel?
  52.    Q07) What books are available for learning about Eiffel?
  53.    Q08) Are any magazines or newsletters available concerning Eiffel?
  54.    Q09) Where can I find Eiffel on the World-Wide-Web?
  55.    Q10) Where can I get an Eiffel editor or emacs-mode?
  56.    Q11) What is BON?
  57.    Q12) How large are typical Eiffel executables?
  58.    Q13) Are there standards for the Eiffel language?
  59.    Q14) How fast do Eiffel applications run?
  60.    Q15) Are there any Eiffel user groups?
  61.    Q16) Where can I get Eiffel products and services?
  62.    Q17) Are there any conferences for Eiffel users?
  63.    Q18) Why do most Eiffel implementations compile to C?
  64.  
  65. Language Issues:
  66.  
  67.    L01) What features does Eiffel have?
  68.    L02) What changes have been made to the Eiffel language definition?
  69.    L03) What libraries come with Eiffel?
  70.    L04) What's the big deal about preconditions and postconditions?
  71.    L05) Please explain and discuss covariance vs. contravariance.
  72.    L06) Is it true that there are "holes" in the Eiffel type system?
  73.    L07) Is there support for concurrency in Eiffel?
  74.    L08) Why doesn't Eiffel allow function overloading?
  75.    L09) Why are there no procedural types in Eiffel?
  76.    L10) Why are there no class attributes in Eiffel?
  77.    L11) How can I call the parent-class version of a redefined
  78.         routine?
  79.    L12) Where can I find a comparison between Eiffel and C++?
  80.    L13) Are there any destructors in Eiffel?
  81.  
  82. N01)   Announce Visual Eiffel for Windows 95/NT
  83.  
  84. The Visual Eiffel for Windows 95/NT is current available for downloading
  85. for a limited evaluation from http://www.eiffel.com.  If you have any 
  86. questions,  please send e-mail to info@eiffel.com or call (805)
  87. 685-1006.
  88.  
  89. ----------
  90.  
  91. N02)   ISE Eiffel 4 for Windows
  92.  
  93. Here it is! ISE Eiffel 4 for Windows is now available for downloading. 
  94. Just get it from our site or one of the mirrors, try it for free. You'll 
  95. love it! 
  96.  
  97. What you will get 
  98.  
  99. ISE Eiffel 4 is the latest in the acclaimed ISE Eiffel product line. 
  100. In the downloadable Windows version you will get: 
  101.  
  102. o    The acclaimed EiffelBench environment for fast incremental
  103.     recompilation (melting), C code generation, finalization of optimized
  104.     executables, graphical browsing, automatic documentation tools 
  105.     (including generation of HTML, RTF, MML and other formats), debugging,
  106.     object inspection etc. 
  107.  
  108. o    Extensive on-line documentation. 
  109.  
  110. o    Extensive reusable libraries (several hundred classes!): EiffelBase, 
  111.     the most thoroughly designed library covering fundamental structures 
  112.     of software engineering, from stacks and queues to files and 
  113.     iterators; WEL, the Windows Eiffel Library, for building robust 
  114.     graphical applications taking full advantage of the Windows API. 
  115.     These libraries come precompiled. 
  116.  
  117. o    C and C++ interface. 
  118.  
  119. o    The Eiffel Resource Bench: generate a Windows graphical application,
  120.     using WEL, from a resource file produced by a Windows GUI builder such
  121.     as Microsoft Developer's Studio. 
  122.  
  123. If you have any questions,  please send e-mail to info@eiffel.com or 
  124. call (805) 685-1006.
  125.  
  126. ----------
  127.  
  128. N03)    The long awaited "Object Oriented Software Construction 2ed" by
  129.     Bertrand Meyer
  130.  
  131. Overview
  132.  
  133. Object-Oriented Software Construction, second edition is the
  134. comprehensive reference on all aspects of object technology, from
  135. design principles to O-O techniques, Design by Contract, O-O
  136. analysis, concurrency, persistence, abstract data types and many
  137. more. Written by a pioneer in the field, contains an in-depth analysis
  138. of both methodological and technical issues.
  139.  
  140. Comes with a CD-ROM containing: the complete hyperlinked text,
  141. for easy reference; software to read the text on major industry
  142. platforms; supplementary material (reusable components,
  143. mathematical complements); and a complete graphical O-O
  144. development environment supporting the concepts of the book.
  145.  
  146. Ordering Information
  147.  
  148. Title:    Object-Oriented Software Construction, second edition, 1997, 1300
  149. pp.
  150. Author:    Bertrand Meyer, ISE Inc., Santa Barbara, CA
  151. ISBN:    SBN 0-13-629155-4
  152.  
  153. Contacting ISE 
  154.  
  155. WWW Site:    http://www.eiffel.com
  156. E-mail:        info@eiffel.com
  157. Phone:        (805) 685-1006
  158.  
  159. ----------
  160.  
  161. Q01)   What is Eiffel?
  162.  
  163. Eiffel is an advanced object-oriented programming language that
  164. emphasizes the design and construction of high-quality and reusable
  165. software.
  166.  
  167. Eiffel is not a superset or extension of any other language. Eiffel
  168. strongly encourages OO programming and does not allow dangerous
  169. practices from previous generation languages although it does
  170. interface to other languages such as C and C++. Eiffel supports the
  171. concept of "Design by Contract" to improve software correctness.
  172.  
  173. Beyond the language aspect Eiffel may be viewed as a method of
  174. software construction. Eiffel is an excellent vehicle for software
  175. education, including for a first programming course.
  176.  
  177. ----------
  178.  
  179. Q02)   Where did Eiffel come from?
  180.  
  181. Eiffel was created by Bertrand Meyer and developed by his company,
  182. Interactive Software Engineering (ISE) of Goleta, CA.
  183.  
  184. Dr. Meyer borrowed on his extensive experience with OOP, particularly
  185. with Simula. He also added in important concepts from his academic
  186. work on software verification and computer language definition.
  187.  
  188. Eiffel's design addresses many practical concerns that software
  189. engineers face when creating complex software. Eiffel has evolved
  190. continually since its conception on September 14, 1985 and its first
  191. introduction in 1986.
  192.  
  193. Eiffel is named after Gustave Eiffel, the engineer who designed the
  194. Eiffel Tower.
  195.  
  196. ----------
  197.  
  198. Q03)   What Eiffel products are available?
  199.  
  200. Commercial Eiffel compilers, libraries and tools are available from
  201. the following vendors and their resellers:
  202.  
  203.   Interactive Software Engineering Inc (ISE Eiffel)
  204.   Tower Technology Corporation (TowerEiffel)
  205.   SIG Computer GmbH (Eiffel/S)
  206.   Jan Willamowius (Eiffel adaption of SNiFF+ Programming Environment)
  207.  
  208. The following platforms are supported by one or more of the above
  209. vendors:
  210.  
  211.   PC: DOS, OS/2, Windows 3.1, Windows 95, Windows NT, PC Unix
  212.     (Interactive, SCO, and ESIX), Nextstep, Linux
  213.   OTHER HARDWARE: Sparc (SunOS & Solaris), NeXTStep, HP9000, DEC 5xxx,
  214.     Sony News, DG Aviion, DEC Alpha OSF-1, DEC OpenVMS, RS6000,
  215.     Pyramid, QNX, Silicon Graphics, Macintosh (Motorola & PowerPC)
  216.  
  217. Special offers are available on many of these products for personal or
  218. educational use.
  219.  
  220. Further information about these products is available from the vendors
  221. by email and on the world-wide-web.
  222.  
  223. See Q16 for contact details and websites.
  224.  
  225. ----------
  226.  
  227. Q04)   Is Eiffel available for free or as shareware?
  228.  
  229. All of Eiffel - All graphical - All for free!
  230.  
  231. FREE EIFFEL FOR WINDOWS is a free version of ISE's acclaimed Melting Ice
  232. Technology compiler and environment for Eiffel. No strings attached --
  233. it's
  234. FREE!
  235.  
  236.        FREE EIFFEL FOR WINDOWS is now fully graphical, showing the power
  237. of
  238.        the EiffelBench set of advanced development tools for fast
  239.        compilation, documentation, browsing, debugging and much more!
  240.  
  241.        The earlier text-based environment is still available, but we
  242. think
  243.        you'll want to try the graphical environment right away!
  244.  
  245. Technical support for FREE EIFFEL FOR WINDOWS is available. Details are
  246. included in the delivery, or contact us.
  247.  
  248. Also of interest
  249.  
  250. Upgrade to Personal or Professional Eiffel for Windows for an unbeatable
  251. price and get printed documentation, more tools, more libraries, support
  252. and
  253. more.
  254.  
  255. Also note our highly affordable ISE Eiffel for Linux , supporting the
  256. entire
  257. set of ISE Eiffel mechanisms for the fastest growing version of Unix.
  258. And of
  259. course ISE Eiffel is available for the major platforms in the industry,
  260. from
  261. Unix to VMS with more to come.
  262.  
  263. Getting familiar with the environment
  264.  
  265. On-line documentation is included in the delivery. But please do us a
  266. favor:
  267. if you are new to ISE Eiffel, please take a few minutes (now or later,
  268. but
  269. before you start using the environment) to consult the on-line
  270. introduction
  271. to EiffelBench. The powerful interaction techniques of ISE Eiffel are
  272. innovative and have been known to startle newcomers. We are sure you
  273. will
  274. love them, but first you must read about the essential ideas.
  275.  
  276. Downloading FREE EIFFEL 4.0 FOR WINDOWS
  277.  
  278. Note: if you want the graphical version (who doesn't?) do NOT download
  279. it
  280. from SimTel or any of the other sites. At the moment only ISE's site has
  281. FREE GRAPHICAL EIFFEL FOR WINDOWS.
  282.  
  283. Be sure to choose the version for the appropriate variant of Windows, as
  284. listed below: Windows 95, Windows NT or Windows 3.1. The Windows 3.1
  285. version
  286. will NOT work under 95 or NT.
  287.  
  288. To download the FREE GRAPHICAL EIFFEL FOR WINDOWS, go to the ISE Web
  289. Site:
  290.  
  291.   From the WWW:  http://www.eiffel.com
  292.   Directly from FTP:  ftp.eiffel.com
  293.  
  294. SIG Computer's "Eiffel/S 1.3s" is a shareware version of their Eiffel
  295. compiler for DOS and Unix and is available by FTP from SimTel mirror
  296. sites in SimTel/msdos/eiffel, or from the UWCC archive
  297. at
  298.  
  299.   ftp//ftp.cm.cf.ac.uk/pub/Eiffel/SIG/Eiffel-S-1.3/
  300.  
  301. The EON Eiffel compiler is shareware under MS-DOS and Linux, and a
  302. beta-test version is available from
  303.  
  304.   ftp://ftp.demon.co.uk/pub/eiffel/eon-eiffel/
  305.  
  306. SmallEiffel is a free Eiffel compiler distributed under the terms of
  307. the GNU General Public License as published by the Free Software
  308. Foundation.  You can download SmallEiffel at
  309.  
  310.   ftp://ftp.loria.fr/pub/loria/genielog/SmallEiffel
  311.  
  312. The following Eiffel archive sites allow anonymous file transfer:
  313.  
  314. ftp://ftp.tu-clausthal.de/pub/atari/languages/eiffel/vici_102.lzh
  315.   The Atari ST interpreter referred to above.
  316.  
  317. ftp://ftp.cm.cf.ac.uk/pub/eiffel
  318.   University of Wales. Contains the latest version of this FAQ, plus
  319.   the front-end parser (ep) and various public domain classes. To
  320.   contribute, contact Ted Lawson (ted@cm.cf.ac.uk).
  321.  
  322. ftp://ftp.fu-berlin.de/pub/unix/languages/heron
  323.   This is an Eiffel front-end parser (HERON) in the public domain,
  324.   created by Burghardt Groeber and Olaf Langmack of the Freie
  325.   Universitaet in Berlin.
  326.  
  327. ftp://ftp.informatik.uni-stuttgart.de/pub/eiffel
  328.   Falkultaet Informatik der Universitaet Stuttgart, Germany. Contains
  329.   a compiler generator, several encapsulations, a pretty-printer for
  330.   Eiffel/S, and some utility classes. To contribute, contact Joerg
  331.   Schulz (schulz@adam.informatik.uni-stuttgart.de).
  332.  
  333. ftp://utarlg.uta.edu/CSE/EIFFEL
  334.   UT-Arlington, USA. Contains some code from Eiffel Outlook back
  335.   issues.
  336.  
  337. SIG Computer produces a CD-ROM containing most of the available
  338. freeware, shareware and public domain Eiffel material.
  339.  
  340. ----------
  341.  
  342. Q05)   Is there an archive of the comp.lang.eiffel newsgroup?
  343.  
  344. Yes, at the following FTP sites:
  345.  
  346.   ftp://wuarchive.wustl.edu/usenet/comp.lang.eiffel/
  347.  
  348. and on the WWW at http://www.cm.cf.ac.uk/CLE/
  349.  
  350. ----------
  351.  
  352. Q06)   What is Sather? How does it compare to Eiffel?
  353.  
  354. Sather is an OO language, originally patterned after Eiffel but now
  355. very different, created at ICSI of Berkeley, CA.
  356.  
  357. Sather does not support Design by Contract, but has some other
  358. interesting features. See the usenet newsgroup comp.lang.sather.
  359.  
  360. ----------
  361.  
  362. Q07)   What books are available for learning about Eiffel?
  363.  
  364. The classic text for learning about Eiffel (and OO programming in
  365. general) is Dr. Meyer's "Object Oriented Software Construction".
  366. Although the language has evolved significantly since the book was
  367. published, the presentation of the basic problems and solutions which
  368. motivate the OO mind set are still quite compelling. This is the book
  369. to get if you are new to the object-oriented world (Prentice Hall,
  370. ISBN 13-629031-0). Available in French as "Conception et Programmation
  371. par Objets" (90/10 InterEditions, ISBN 2-7296-0272-0) and in German as
  372. "Objektorientierte Softwareentwicklung (Hanser, ISBN 3-446-15773-5).
  373.  
  374. Also by Dr. Meyer, "Eiffel: The Language", combines an introduction to
  375. Eiffel, the language reference, and a good deal of philosophy into its
  376. 600 pages. This is a rigorous and comprehensive book which some
  377. readers may find heavy going despite Dr. Meyer's clarity of
  378. expression. It is the definitive language reference, and essential
  379. reading for all serious Eiffel users. Get the second or later printing
  380. (same ISBN), which includes many corrections and changes (there is not
  381. a second edition, and none is currently underway) (Prentice Hall, ISBN
  382. 13-247925-7). Available in French as "Eiffel, le langage" (94/10
  383. InterEditions, ISBN 2-7296-0525-8).
  384.  
  385. Dr. Meyer and Jean-Marc Nerson have edited "Object-Oriented
  386. Applications". It includes an introduction to Eiffel technology
  387. followed by seven in-depth descriptions of large applications written
  388. in Eiffel. (Prentice Hall, ISBN 13-013798-7)
  389.  
  390. Robert Switzer has written "Eiffel: An Introduction". This is a very
  391. clear and concise Eiffel primer, with many code fragments and two
  392. substantial Eiffel applications. (Prentice Hall, ISBN 13-105909-2).
  393. Available in French as "Introduction a Eiffel" (Masson, ISBN
  394. 2-225-84-656-1)
  395.  
  396. ISE distributes a set of 6 video lectures entitled "Object-Oriented
  397. Software Construction", taught by Bertrand Meyer. These provide an
  398. overall introduction to the method and use ISE Eiffel 3 to illustrate
  399. the concepts.
  400.  
  401. Frieder Monninger's book "Eiffel: Objektorientiertes Programmieren in
  402. der Praxis" is a very down-to-earth Eiffel handbook in German. (Heise,
  403. ISBN 3-88229-028-5).
  404.  
  405. Bertrand Meyer's "Reusable Software: The Base Object-Oriented
  406. Component Libraries" (Prentice Hall, ISBN 0-13-245499-8, about 530
  407. pages) describes principles of library design and the taxonomy of
  408. fundamental computing structures. Serves as a manual for the
  409. EiffelBase libraries.
  410.  
  411. Bertrand Meyer's "An Object-Oriented Environment: Principles and
  412. Application" (Prentice Hall, ISBN 0-13-245507-2, 240 pages) describes
  413. the ISE EiffelBench environment as well as the "Melting Ice"
  414. compilation technology and the EiffelBuild GUI application builder.
  415.  
  416. Richard Wiener's "Software Development Using Eiffel: There can be life
  417. other than C++" (Prentice-Hall, ISBN 0-13-100686-X) is a useful book
  418. (full of serious code samples) for those with a grounding in another
  419. OO language.
  420.  
  421. A book by Kim Walden and Jean-Marc Nerson, "Seamless Object-Oriented
  422. Software Architecture: Analysis and Design of Reliable Systems",
  423. describes the BON method in detail (Prentice Hall, ISBN
  424. 0-13-031303-3).
  425.  
  426. Pete Thomas and Ray Weedon's "OO Programming in Eiffel" is a very
  427. comprehensive Eiffel tutorial and textbook, with a solid "Abstract
  428. Data Type" approach (Addison-Wesley, ISBN 0-201-59387-4).
  429.  
  430. Another book called "OO Programming in Eiffel" is by Robert Rist and
  431. Robert Terwilliger, and is a textbook with an emphasis on design.
  432. (Prentice-Hall, ISBN 0-13-205931-2).
  433.  
  434. Bertrand Meyer's "Object Success" is a manager's guide to object
  435. orientation, its impact on the corporation and its use for
  436. re-engineering the software process (Prentice-Hall, ISBN
  437. 0-13-192833-3).
  438.  
  439. Macmillan publishes John Tyrrell's inexpensive and very approachable
  440. textbook "Eiffel Object-Oriented Programming" (ISBN 0-333-64554-5).
  441.  
  442. "Object-Oriented Software Engineering with Eiffel"
  443. By Jean-Marc Jezequel, Addison-Wesley Eiffel in Practice Series
  444. ISBN 0-201-63381-7 * Paperback * 368 pages * ) 1996
  445.  
  446. "Object Technology for Scientific Computing Object-Oriented Numerical
  447. Software
  448. in Eiffel and C" by Paul Dubois, (Prentice Hall and its editor for the
  449. Object
  450. Oriented Series, (ISBN 0-13-267808-X * paper * 350 pages * Accompanying
  451. CD with
  452. the Free Eiffel for UNIX & Linux environments)
  453.  
  454. There is also a white paper titled 'Eiffel: A Manager's Perspective'
  455. which provides a quick introduction to Eiffel and the benefits it
  456. brings to the software development process. For a free copy, send your
  457. name and postal address to tower@twr.com
  458.  
  459. ----------
  460.  
  461. Q08)   Are any magazines or newsletters available concerning Eiffel?
  462.  
  463. Eiffel Outlook is a bi-monthly journal devoted to Eiffel, published
  464. since 1991. Topics cover all areas of interest to the Eiffel
  465. community.
  466.  
  467. Subscriptions, trial subscriptions and back issues are available from:
  468.  
  469.    SIG Computer in Germany
  470.    Everything Eiffel in the UK & France
  471.    Simon Parker in Ireland
  472.    IMSL in Japan
  473.    Enea Data in Sweden
  474.    Tower Technology in the USA and all other countries
  475.  
  476. Details are available at <http://www.cm.cf.ac.uk/Tower/Outlook.html>
  477. or by sending email to <outlook@twr.com>.
  478.  
  479. ISE produces a newsletter "Eiffel World". Subscriptions are free
  480. (email your request to info@eiffel.com). Individual copies are
  481. available from:
  482.  
  483.    Cybertech in Argentina
  484.    Class Technology in Australia
  485.    Jay-Kell Technologies in Canada
  486.    SOL in France
  487.    SIG Computer in Germany
  488.    Eiffel Ireland in Ireland
  489.    Etnoteam in Italy
  490.    Information & Math Science Lab
  491.    Software Research Associates in Japan
  492.    Chromasoft in Mexico
  493.    Science OO Products & Systems in the Netherlands
  494.    Objective Methods in New Zealand
  495.    Ruperez & Associates in Spain
  496.    Enea Data in Sweden
  497.    Abstraction in Switzerland
  498.    Everything Eiffel in the UK
  499.  
  500.    Also, EiffelWorld is now available on-line! This is your first
  501.    quarterly reminder to visit the EiffelWorld Online magazine at
  502.  
  503.    http://www.eiffel.com/doc/eiffelworld/5.2
  504.  
  505. If you're interested in Software Design Patterns you may like to
  506. subscribe to the Eiffel Patterns mailing list. Send email to:
  507.  
  508.    e-patterns-request@cbr.dit.csiro.au
  509.  
  510. ----------
  511.  
  512. Q09)   Where can I find Eiffel on the World-Wide-Web?
  513.  
  514. An Eiffel home page is held on the University of Wales College of
  515. Cardiff's server at http://www.cm.cf.ac.uk/CLE/. Vendor websites are
  516. listed in Q16.
  517.  
  518. ----------
  519.  
  520. Q10)   Where can I get an Eiffel editor or emacs-mode?
  521.  
  522. Franck Arnaud's Eiffel extension to the Windows/WindowsNT programmers
  523. editor Codewright from Premia allows you to see Eiffel code in colour,
  524. has smart indenting and a few templates. Available by anonymous FTP
  525. from ftp://ftp.cm.cf.ac.uk/pub/eiffel/tools/cweiffel.zip
  526.  
  527. The WINEDIT shareware programmer's editor offers colour syntax
  528. highlighting, works with Eiffel/S under MS-Windows, and is available
  529. from:
  530. ftp://src.doc.ic.ac.uk/computing/systems/ibmpc/windows3/programr/we-30d.zip
  531. and ftp://gatekeeper.dec.com/.f/micro/msdos/win3/programr/we-30d.zip
  532.  
  533. Alan Philips' free Programmers File Editor also works with Eiffel/S
  534. under MS-Windows, has templates but not syntax highlighting, available
  535. from ftp://ftp.demon.co.uk/pub/ibmpc/windows/editors/pfe0507.zip
  536.  
  537. Tower Technology Corporation supplies an Eiffel 3 emacs mode that
  538. supports syntax-directed highlighting, auto-indentation and is easily
  539. customized for font use, color and indentation amounts. It comes as
  540. part of the TowerEiffel system, but is also available free for anyone
  541. who requests it. Send email to elisp@atlanta.twr.com to get the latest
  542. version.
  543.  
  544. ----------
  545.  
  546. Q11)   What is BON?
  547.  
  548. BON ("Business Object Notation") is a method for high-level analysis
  549. and design, offering a seamless reversible transition to an Eiffel
  550. implementation. The method emphasizes Design by Contract and
  551. systematic development.
  552.  
  553. ISE supports BON with its EiffelCASE tool.
  554.  
  555. ----------
  556.  
  557. Q12)   How large are typical Eiffel executables?
  558.  
  559. (How large are typical C executables?)
  560.  
  561. In general, the size of an executable depends on the compiler used.
  562. Thus, a good Eiffel compiler would produce good C code by removing
  563. dead code such that a C executable is not smaller than an Eiffel
  564. executable.  This is true of SmallEiffel and ISE Eiffel compilers.
  565. Also, I think this is similar for others like Tower Eiffel and SIG
  566. Eiffel compilers.
  567.  
  568. Interestingly, Eiffel applications seem to grow less rapidly as new
  569. capabilities are added. Reuse does help out tremendously in this
  570. regard. A good Eiffel compiler allows large applications to be smaller
  571. than equally functional applications written in C.
  572.  
  573. Note that leaving assertion checking in the code increases the size of
  574. applications a lot. Despite this, many of us prefer that they remain
  575. throughout development. Some even deliver a PRECONDITIONS-only version
  576. of their applications to their early customers.
  577.  
  578. ----------
  579.  
  580. Q13)   Are there standards for the Eiffel language?
  581.  
  582. The definition of the Eiffel language is in the public domain. This
  583. definition is controlled by NICE, the Non-profit International
  584. Consortium for Eiffel. This means that anyone or any company may
  585. create a compiler, interpreter, or whatever having to do with Eiffel.
  586. NICE reserves the right to validate that any such tool conforms to the
  587. current definition of the Eiffel language before it can be distributed
  588. with the Eiffel trademark. (i.e. advertised as an "Eiffel" compiler.)
  589.  
  590. The Eiffel trademark is owned and controlled by NICE. NICE is using
  591. Bertrand Meyer's book, "Eiffel: The Language" (2nd Printing), as the
  592. initial definition of the language.
  593.  
  594. The NICE board of directors for 1995 consists of Christine Mingins
  595. (chair), Bertrand Meyer (treasurer), Simon Parker (secretary) and Paul
  596. Johnson.
  597.  
  598. In June 1995 NICE published the first version (called "Vintage 95") of
  599. the Eiffel Library Standard. Those parts of an Eiffel application that
  600. use only the standard classes and features should run with minimal
  601. change on any compiler supporting ELS-95.
  602.  
  603. NICE (Nonprofit International Consortium for Eiffel)
  604. 45 Hazelwood
  605. Shankill
  606. Co Dublin
  607. Republic of Ireland
  608. TEL: +353 1 282 3487
  609. email: nice@atlanta.twr.com
  610.  
  611. ----------
  612.  
  613. Q14)   How fast do Eiffel applications run?
  614.  
  615. Early versions of Eiffel were slow. Recent implementations have
  616. improved dramatically. However, to achieve maximum performance under
  617. any Eiffel implementation, run-time assertion monitoring must be
  618. switched off. (But see Q12 on when to switch assertions on or off.)
  619.  
  620. It's hard to generalise, but compared to C++, simple
  621. computation-intensive applications will run perhaps 15% slower. Large
  622. applications are often dominated by memory management rather than
  623. computation. ISE recently demonstrated that by simply adding a call to
  624. the garbage collector's "full-collect" routine at a time when there
  625. were known to be few live objects, performance became dramatically
  626. faster than a corresponding C++ version.
  627.  
  628. ----------
  629.  
  630. Q15)   Are there any Eiffel user groups?
  631.  
  632. International Eiffel User Group
  633. Darcy Harrison - Attention: IEUG
  634. ISE Inc.
  635. 270 Storke Road, Suite 7
  636. Goleta, CA 93117, USA
  637. TEL (805) 685-1006
  638. FAX (805) 685-6869
  639. darcyh@eiffel.com
  640.  
  641. UK & Ireland Eiffel Interest Group (currently inactive)
  642.  
  643. GUE, Groupe des Utilisateurs Eiffel (France)
  644. Jean-Marc Nerson
  645. 104 rue Castagnary, 75015 Paris
  646. TEL +33 1 45 32 58 80
  647. FAX +33 1 44 32 58 81
  648. marc@eiffel.fr
  649. (meets every 2 months or so)
  650.  
  651. TowerEiffel User's Group
  652. Private cyberspace mailing list for supported Tower customers with
  653. meetings coinciding with major OO Conferences and Events.
  654.  
  655. ----------
  656.  
  657. Q16)   Where can I get Eiffel products and services?
  658.  
  659. These vendors, resellers and suppliers of Eiffel training and
  660. consultancy are listed in alphabetical order:
  661.  
  662. Argentina
  663.  
  664. Cybertech
  665. Systens Integration for CIM
  666. Suarez 1281, Third Floor,Apt.A
  667. CP-1288 Buenos Aires
  668. TEL +54 1 28 1950
  669. FAX +54 1 322 1071 or 963 0070
  670.  
  671.  
  672. Australia
  673.  
  674. Class Technology Pty. Ltd.
  675. PO Box 6274
  676. North Sydney NSW 2060
  677. TEL +61 2 9922 7222
  678. FAX +61 2 9922 7703
  679. email eiffel@class.com.au
  680. http://www.class.com.au/
  681.  
  682.  
  683. Canada
  684.  
  685. Jay-Kell Technologies, Inc.
  686. 48 Lakeshore Road, Suite #1
  687. Pointe Claire, Quebec
  688. Canada H9S 4H4
  689. TEL +51 4 630 1005
  690. FAX +51 4 630 1456
  691.  
  692.  
  693. France
  694.  
  695. SOL
  696. 104 rue Castagnary
  697. 75015 Paris
  698. TEL +33 1 45 32 58 80
  699. FAX +33 1 45 32 58 81
  700. email eiffel@eiffel.fr
  701.  
  702.  
  703. Germany
  704.  
  705. Feinarbeit
  706. Altenbraker Strasse 4
  707. D-12053 Berlin
  708. TEL +49 30 6215827
  709. FAX +49 30 6215863
  710. email langmack@netmbx.netmbx.de
  711.  
  712. SIG Computer GmbH
  713. Zu den Bettern 4
  714. D 35619 Braunfels, Germany
  715. TEL +49 6472 2096
  716. FAX +49 6472 7213
  717. email eiffel@eiffel.de
  718. www http://www.sigco.com/
  719.  
  720. Jan Willamowius
  721. Semperstr. 1
  722. D-22303 Hamburg
  723. Hamburg, Germany
  724. Tel: +49 40-2806209
  725. Email: jan@janhh.shnet.org
  726. WWW: http://swt1.informatik.uni-hamburg.de/~1willamo/dl.html
  727.  
  728. Halstenbach ACT GmbH
  729. Dr. Joachim Wolffram
  730. Breidenbrucher Strasse 2
  731. D-51674 Wiehl-Bomig
  732. Tel.: +49 2261 9902-0
  733. email: info@halstenbach.de
  734. WWW: http://www.halstenbach.de
  735.  
  736.  
  737. Ireland
  738.  
  739. Eiffel Ireland
  740. 45 Hazelwood
  741. Shankill
  742. Co Dublin
  743. TEL +353 1 282 3487
  744. email sparker@eiffel.ie
  745. www http://www.eiffel.ie/Eiffel/
  746.  
  747.  
  748. India
  749.  
  750. Sritech Information Technology
  751. 744/51 2nd Floor
  752. 10 Mian Road, 4th Block
  753. Jayanagar, Bangalore, India 560011
  754. TEL +91 812 640661
  755. FAX +91 812 643608
  756.  
  757.  
  758. Italy
  759.  
  760. EtnoTeam
  761. Via Adelaide Bono Cairoli 34
  762. 20217 Milano
  763. TEL +39 2 261621
  764. FAX +39 2 26110755
  765. email sales@etnomi.it
  766.  
  767.  
  768. Japan
  769.  
  770. Information and Math Science Lab Inc.
  771. 2-43-1, Ikebukuro, Toshima-ku
  772. Tokyo 171
  773. email fushimi@idas.imslab.co.jp
  774. TEL +81 3 3590 5211
  775. FAX +81 3 3590 5353
  776.  
  777. Software Research Associates
  778. 1-1-1 Hirakawo-Cho
  779. Chiyoda-ku Tokyo 102
  780. TEL +81 3 3234 8789
  781. FAX +81 3 3262 9719
  782. email sugita@sra.co.jp
  783.  
  784.  
  785. Mexico
  786.  
  787. Cromasoft SA de CV
  788. Mazatlan 161
  789. Col Condesa, 06140 Mexico
  790. TEL +52 5 286 82 13
  791. FAX +52 5 286 80 57
  792. email claudio@croma.sunmexico.sun.com
  793.  
  794.  
  795. The Netherlands
  796.  
  797. SOOPS
  798. Sarphatistraat 133
  799. NL-1018 GC Amsterdam, The Netherlands
  800. TEL +31 20 525 6644
  801. FAX +31 20 624 6392
  802. email A731CISK@HASARA11.BITNET
  803.  
  804.  
  805. New Zealand
  806.  
  807. Objective Methods Ltd
  808. PO Box 17356 (77 Chamberlain Rd)
  809. Karori, Wellington, New Zealand
  810. TEL +64 4 476 9499
  811. FAX +64 4 476 9237 or 8772
  812. email dkenny@swell.actrix.gen.nz
  813.  
  814.  
  815. Russia
  816. SIG Computer, Germany has a branch office in Moscow.
  817. email eiffel@sigcomp.msk.su
  818.  
  819.  
  820. Spain
  821.  
  822. Eiffel Iberica
  823. Aptdo 1646
  824. 20080 San Sebastian
  825. TEL +34 943 471906
  826. email ean@sc.ehu.es
  827.  
  828. Ruperez & Associates
  829. c/San Bartolome 21, 5F
  830. 20001 San Sebastian
  831. TEL +34 43 461801
  832. email jipferur@si.ehu.es
  833.  
  834.  
  835. Sweden
  836.  
  837. Enea Data
  838. Box 232, Nytorpsvagen 5
  839. S-183 23 Taby
  840. TEL +46 8 792 25 00
  841. FAX +46 8 768 43 88
  842. email eiffel@enea.se
  843.  
  844.  
  845. Switzerland
  846.  
  847. Abstraction
  848. 18 Faubourg de l'Hopital
  849. 2000 Neuchatel
  850. TEL +41.38.25.04.93
  851. FAX +41.38.259.857
  852. email silberstein@clients.switch.ch
  853.  
  854. Objectif Concept
  855. Passage Cour-Robert 5
  856. CH 1700 Fribourg
  857. TEL +41 37 232977
  858. FAX +41 37 464889
  859.  
  860.  
  861. United Kingdom
  862.  
  863. Eon Software
  864. 19 Stapleton Road
  865. Heddington, Oxford OX3 7LX
  866. TEL +44 865 741452
  867. email ian@eonsw.demon.co.uk
  868.  
  869. Everything Eiffel
  870. 6 Bambers Walk
  871. Wesham PR4 3DG
  872. England
  873. TEL & FAX +44 1772 687525
  874. email rogerb@eiffel.demon.co.uk
  875.  
  876.  
  877. United States of America
  878.  
  879. Interactive Software Engineering, Inc
  880. 270 Storke Road, Suite 7
  881. Goleta, CA 93117
  882. TEL 805-685-1006
  883. FAX 805-685-6869
  884. email info@eiffel.com
  885. www http://www.eiffel.com/
  886.  
  887. Tower Technology Corporation
  888. 1501 Koenig Lane
  889. Austin, TX 78756 USA
  890. TEL 512-452-9455
  891. FAX 512-452-1721
  892. email: tower@twr.com
  893. www http://www.twr.com/
  894.  
  895. ZumaSoft
  896. 6235 Paseo Canyon Drive
  897. Malibu, California 90265, USA
  898. TEL & FAX +1 310 457-6263
  899. email tstevens@netcom.com
  900.  
  901. ----------
  902.  
  903. Q17)   Are there any conferences for Eiffel users?
  904.  
  905. The conferences listed here are not just for Eiffel. Eiffel shares the
  906. spotlight with other OO languages including C++ and Smalltalk.
  907.  
  908. Feb 26 - 29 1996
  909. TOOLS Europe, Paris France
  910.  
  911. Jul 29 - Aug 2 1996
  912. TOOLS USA, Santa Barbara California
  913.  
  914. TOOLS is the major international conference devoted to the
  915. applications of OO technology. Other events, such as Eiffel User Group
  916. meetings or NICE meetings are often held in conjunction with TOOLS.
  917.  
  918. TOOLS Conferences
  919. PO Box 6863, Santa Barbara, CA 93160, USA
  920. TEL (805) 685 1006, FAX (805) 685 6869
  921. email tools@tools.com
  922.  
  923. ----------
  924.  
  925. Q18)   Why do most Eiffel implementations compile to C?
  926.  
  927. By using C as a target language, an Eiffel implementor can:
  928.  
  929. -  bring Eiffel to the marketplace faster and at lower cost
  930. -  port their implementation more easily to other platforms
  931. -  take advantage of optimisation provided by the C compiler
  932.  
  933. Much of the technology that makes Eiffel relatively simple to use also
  934. makes it more difficult to implement (an Eiffel-to-C compiler is
  935. perhaps 4 to 5 times more difficult to create than a native Pascal
  936. compiler).
  937.  
  938. Compiling Eiffel to C seems to work well under Unix. C is sometimes
  939. thought of as the native code of Unix.
  940.  
  941. On the other hand, C is not universal on other platforms, and the
  942. Eiffel purchaser may need to buy a C compiler as well, and possibly
  943. replace it if the supported C compilers change with new versions of
  944. the Eiffel compiler.
  945.  
  946. With a native-code compiler, you'd get somewhat better throughput and
  947. the potential for smaller executables and slightly better performance.
  948. You'd also get a higher price and an even longer wait for Eiffel to
  949. show up on other than the leading market share machines.
  950.  
  951. ----------
  952.  
  953. L01)   What features does Eiffel have?
  954.  
  955. Eiffel is a pure object-oriented language. Its modularity is based on
  956. classes. It stresses reliability, and facilitates design by contract.
  957. It brings design and programming closer together. It encourages the
  958. re-use of software components.
  959.  
  960. Eiffel offers classes, multiple inheritance, polymorphism, static
  961. typing and dynamic binding, genericity (constrained and
  962. unconstrained), a disciplined exception mechanism, systematic use of
  963. assertions to promote programming by contract, and deferred classes
  964. for high-level design and analysis.
  965.  
  966. Eiffel has an elegant design and programming style, and is easy to
  967. learn.
  968.  
  969. An overview is available at
  970. http://www.eiffel.com/doc/manuals/language/intro/
  971.  
  972. ----------
  973.  
  974. L02)   What changes have been made to the Eiffel language definition?
  975.  
  976. Eiffel is still a relatively new language, and there have been a
  977. number of changes to its definition. Here is a summary of the major
  978. changes:
  979.  
  980. 1. Changes between the publication of "Object-Oriented Software
  981.    Construction" in 1988, and the release of Eiffel 2.3:
  982.  
  983.    - Constrained genericity enables a generic class to restrict its
  984.      generic parameters to the descendants of a given class
  985.  
  986.    - The "indexing" clause allows information about a class to be
  987.      recorded for extraction by archival, browsing and query tools
  988.  
  989.    - The assignment attempt operator "?=" provides a way to make
  990.      type-safe assignments going against the inheritance hierarchy
  991.  
  992.    - User-defined infix and prefix operator features
  993.  
  994.    - Expanded types support composite objects without dynamic
  995.      allocation, and with value semantics
  996.  
  997.    - The "obsolete" clause for smooth library evolution
  998.  
  999.    - The "unique" keyword for implicitly-assigned integer codes
  1000.  
  1001.    - The multi-branch instruction (similar to a case statement)
  1002.  
  1003.    - The boolean operator for implication ("implies")
  1004.  
  1005. 2. Changes with the introduction of Eiffel Version 3:
  1006.  
  1007.    - The feature adaptation subclause must now be terminated with
  1008.      "end"
  1009.  
  1010.    - Semicolons as instruction separators are optional
  1011.  
  1012.    - Groups of features are bracketed by a feature clause. All
  1013.      features are exported unless the feature clause specifies a
  1014.      restriction. The repeat subclause is no longer needed, because
  1015.      inherited features keep the original export status they had in
  1016.      the parent unless they are redefined, or are the subject of an
  1017.      export subclause in the feature adaptation clause.
  1018.  
  1019.    - Preconditions can only be replaced by weaker ones, postconditions
  1020.      can only be replaced by stronger ones. This is now enforced by
  1021.      the language through the use of "require else" in preconditions
  1022.      and "ensure then" in postconditions.
  1023.  
  1024.    - Ambiguities in repeated inheritance are resolved by a "select"
  1025.      clause.
  1026.  
  1027.    - A feature can no longer be replicated and redefined in the same
  1028.      feature adaptation clause, however the same effect can be
  1029.      achieved through repeated inheritance
  1030.  
  1031.    - Two or more features may be defined at the same time (e.g. "f1,
  1032.      f2 is...").
  1033.  
  1034.    - The keyword "frozen" before a feature name prohibits redefinition
  1035.      of the feature in descendants
  1036.  
  1037.    - In an anchored declaration, the anchor may now also be a formal
  1038.      argument of the enclosing routine
  1039.  
  1040.    - A class may have zero, one or more creation procedures,
  1041.      designated with the "creation" keyword. A new creation syntax
  1042.      using the "!!" symbol allows the appropriate creation procedure
  1043.      to be specified. It is also possible to directly create an object
  1044.      of any type which conforms to the entity to which it is being
  1045.      attached.
  1046.  
  1047.    - The meaning of dot notation has been made more uniform, and
  1048.      alternative constructs have been provided for the special
  1049.      language-defined features that previously used dot notation:
  1050.          x.Create   is now  !! x
  1051.          y.Clone(x) is now  y := clone(x)
  1052.          x.Forget   is now  x := Void
  1053.          x.Void     is now  x = Void
  1054.          x.Equal(y) is now  equal(x, y)
  1055.  
  1056.    - Manifest arrays can be specified, for example
  1057.          <<"Jan", "Feb", "Mar">>
  1058.      which also provides a way to pass a variable number of arguments
  1059.      to a routine.
  1060.  
  1061.    - The command-line parameters are made available to the creation
  1062.      procedure of the root class as an array of strings.
  1063.  
  1064.    - A default rescue procedure called default_rescue may be defined
  1065.      and inherited.
  1066.  
  1067.    - A class may be declared to be an expanded class, in which case
  1068.      any type based on that class will be expanded.
  1069.  
  1070.    - An object may no longer contain a reference to an expanded object
  1071.      that is a sub-object of another object. Instead, upon assignment
  1072.      of an expanded object to a non-expanded object, the expanded
  1073.      object will be cloned, and a reference to the newly-cloned object
  1074.      will be stored in the non-expanded object.
  1075.  
  1076.    - The operator "div" has been replaced by "//", and the operator
  1077.      "mod" has been replaced by "\\".
  1078.  
  1079. 3. Changes between first and second printings of "Eiffel: The Language"
  1080.  
  1081.    - New basic types INTEGER_REF, REAL_REF, CHARACTER_REF and
  1082.      BOOLEAN_REF etc have been introduced to provide non-expanded
  1083.      basic types.
  1084.  
  1085.    - Introduction of the POINTER type to enable external references to
  1086.      be passed around in Eiffel programs.
  1087.  
  1088.    - Calls from Eiffel to external routines no longer implicitly pass
  1089.      the current object as the first parameter.
  1090.  
  1091.    There are many other (more minor) changes, which Neil Wilson has
  1092.    summarized in ftp.cm.cf.ac.uk:/pub/eiffel/Docs in both Microsoft
  1093.    Rich Text Format and ASCII.
  1094.  
  1095. ----------
  1096.  
  1097. L03)   What libraries come with Eiffel?
  1098.  
  1099. All vendors aim to support the Eiffel Library Standard kernel classes.
  1100.  
  1101. In addition, extensive library classes are supplied with the compilers
  1102. including data structures, graphics, lexical analysis and parsing, IO,
  1103. persistence, formatting and more.
  1104.  
  1105. Contact the vendors for further details.
  1106.  
  1107. ----------
  1108.  
  1109. L04)   What's the big deal about preconditions and postconditions?
  1110.  
  1111. The big deal is that it supports programming by contract. For example,
  1112. preconditions (require clauses) are simple boolean statements that are
  1113. used to check that the input arguments are valid and that the object
  1114. is in a reasonable state to do the requested operation. If not, an
  1115. exception is generated. Similarly, postconditions (ensure clauses)
  1116. make sure that a method has successfully performed its duties, thus
  1117. "fulfilling its contract" with the caller. Invariants are boolean
  1118. expressions that are checked every time an object method returns back
  1119. to a separate object.
  1120.  
  1121. You can use these ideas in any OO programming language, but usually
  1122. must supply your own assertion mechanisms or rely on programmer
  1123. discipline. In Eiffel, the ideas are integrated into the whole fabric
  1124. of the environment. We find them used by:
  1125.  
  1126. -- the exception handling mechanism.
  1127.    (Tracebacks almost always identify the correct culprit code since
  1128.    preconditions almost always denote an error in the calling method,
  1129.    while postconditions denote an error in the called method.)
  1130.  
  1131. -- the automatic compilation system.
  1132.    (Assertions can be disabled entirely or selectively by type on a
  1133.    per class basis.)
  1134.  
  1135. -- the Eiffel compiler
  1136.    (Invariants, preconditions and postconditions are all inherited in
  1137.    a manner that makes logical sense.)
  1138.    (Assertion expressions are not allowed to produce side effects so
  1139.    they can be omitted without effect.)
  1140.  
  1141. -- the automatic documentation tools
  1142.    (Preconditions and postconditions are important statements about
  1143.    what a method does, often effectively describing the "contract"
  1144.    between the caller and callee. Invariants can yield information
  1145.    about legal states an object can have.)
  1146.  
  1147. In the future we expect to see formal methods technology work its way
  1148. into the assertion capability. This will allow progressively more
  1149. powerful constraints to be put into place. In addition, if a
  1150. conjecture by Dr. Meyer bears fruit, the notion of preconditions may
  1151. be extended into an important mechanism for the development of
  1152. parallel programming.
  1153.  
  1154. ----------
  1155.  
  1156. L05)   Please explain and discuss covariance vs. contravariance.
  1157.  
  1158. Consider the following situation: we have two classes PARENT and
  1159. CHILD. CHILD inherits from PARENT, and redefines PARENT's feature
  1160. 'foo'.
  1161.  
  1162.    class PARENT
  1163.       feature
  1164.          foo (arg: A) is ...
  1165.    end
  1166.  
  1167.    class CHILD
  1168.       inherit
  1169.          PARENT redefine foo end
  1170.       feature
  1171.          foo (arg: B) is ...
  1172.    end
  1173.  
  1174. The question is: what restrictions are placed on the type of argument
  1175. to 'foo', that is 'A' and 'B'? (If they are the same, there is no
  1176. problem.)
  1177.  
  1178. Here are two possibilities:
  1179.  
  1180.    (1)  B must be a child of A (the covariant rule - so named because
  1181.         in the child class the types of arguments in redefined
  1182.         routines are children of types in the parent's routine, so the
  1183.         inheritance "varies" for both in the same direction)
  1184.  
  1185.    (2)  B must be a parent of A (the contravariant rule)
  1186.  
  1187. Eiffel uses the covariant rule.
  1188.  
  1189. At first, the contravariant rule seems theoretically appealing. Recall
  1190. that polymorphism means that an attribute can hold not only objects of
  1191. its declared type, but also of any descendant (child) type. Dynamic
  1192. binding means that a feature call on an attribute will trigger the
  1193. corresponding feature call for the *actual* type of the object, which
  1194. may be a descendant of the declared type of the attribute. With
  1195. contravariance, we can assign an object of descendant type to an
  1196. attribute, and all feature calls will still work because the
  1197. descendant can cope with feature arguments at least as general as
  1198. those of the ancestor. In fact, the descendant object is in every way
  1199. also a fully-valid instance of the ancestor object: we are using
  1200. inheritance to implement subtyping.
  1201.  
  1202. However, in programming real-world applications we frequently need to
  1203. specialize related classes jointly.
  1204.  
  1205. Here is an example, where PLOT_3D inherits from PLOT, and
  1206. DATA_SAMPLE_3D inherits from DATA_SAMPLE.
  1207.  
  1208.    class PLOT
  1209.       feature
  1210.          add(arg: DATA_SAMPLE) is ...
  1211.  
  1212.    class PLOT_3D
  1213.       inherit
  1214.          PLOT redefine add end
  1215.       feature
  1216.          add(arg: DATA_SAMPLE_3D) is ...
  1217.  
  1218. This requires the covariant rule, and works well in Eiffel.
  1219.  
  1220. It would fail if we were to put a PLOT_3D object into a PLOT attribute
  1221. and try to add a DATA_SAMPLE to it. It fails because we have used
  1222. inheritance to implement code re-use rather than subtyping, but have
  1223. called a feature of the ancestor class on an object of the descendant
  1224. class as if the descendant object were a true subtype. It is the
  1225. compiler's job to detect and reject this error, to avoid the
  1226. possibility of a run-time type error.
  1227.  
  1228. Here's another example where a real-world situation suggests a
  1229. covariant solution. Herbivores eat plants. Cows are herbivores. Grass
  1230. is a plant. Cows eat grass but not other plants.
  1231.  
  1232.    class HERBIVORE                               class PLANT
  1233.    feature
  1234.       eat(food: PLANT) is ...
  1235.       diet: LIST[PLANT]
  1236.  
  1237.    class COW                                     class GRASS
  1238.    inherit                                       inherit
  1239.       HERBIVORE                                     PLANT
  1240.          redefine eat
  1241.       end
  1242.    feature eat(food: GRASS) is ...
  1243.  
  1244. This does what we want. The compiler must stop us from putting a COW
  1245. object into a HERBIVORE attribute and trying to feed it a PLANT, but
  1246. we shouldn't be trying to do this anyway.
  1247.  
  1248. Also consider the container 'diet'. We are not forced to redefine this
  1249. feature in descendant classes, because with covariant redefinition of
  1250. the argument to 'eat', the feature 'diet' can always contain any
  1251. object that can be eaten (e.g. grass for a cow). (With contravariant
  1252. redefinition of the argument to 'eat', it would be necessary to
  1253. re-open the parent class to make the type of the container 'diet' more
  1254. general).
  1255.  
  1256. To summarise: Real-world problems often lend themselves to covariant
  1257. solutions. Eiffel handles these well. Incorrect programs in the
  1258. presence of covariant argument redefinition can cause run-time type
  1259. errors unless the compiler catches these.
  1260.  
  1261. Sather uses the contravariant rule, but uses separate mechanisms for
  1262. subtyping and code reuse and only allows dynamic binding on true
  1263. subtypes. This seems to make contravariance work well, but it can
  1264. force the Sather programmer to use concrete types when modelling
  1265. covariant problems. Concrete types cannot be further subtyped in
  1266. Sather, so this can reduce the potential for re-use (in Eiffel, any
  1267. type can be further subtyped, but the compiler must check that it is
  1268. used validly).
  1269.  
  1270. ----------
  1271.  
  1272. L06)   Is it true that there are "holes" in the Eiffel type system?
  1273.  
  1274. No. The design of Eiffel makes it possible to catch all type errors at
  1275. compile time, so that an Eiffel program cannot abort with a run time
  1276. type error.
  1277.  
  1278. However, to catch a class of certain more obscure type errors at
  1279. compile time, the compiler must analyse the way that classes interact
  1280. within the entire system, rather than just looking at each class one
  1281. by one.
  1282.  
  1283. There is a proposal underway that, if accepted, will allow compilers
  1284. to check this class of errors by looking at classes and not at the
  1285. whole system.
  1286.  
  1287. Because system-wide compile-time validity checking can be complex,
  1288. some compilers insert run-time traps for these errors instead, and
  1289. some may fail to correctly trap these errors. Ask your Eiffel compiler
  1290. vendor how they handle these type problems.
  1291.  
  1292. ----------
  1293.  
  1294. L07)   Is there support for concurrency in Eiffel?
  1295.  
  1296. Eiffel does not yet support concurrency; neither do current commercial
  1297. compilers. However, work on concurrency for Eiffel is a hot research
  1298. topic.
  1299.  
  1300. For four articles on concurrency facilities for Eiffel, including
  1301. Bertrand Meyer's article "Systematic Concurrent Object-Oriented
  1302. Programming", see the September 1993 "Communications of the ACM" (Vol.
  1303. 36, Number 9).
  1304.  
  1305. At least one of these articles can also be obtained from ISE's WWW
  1306. site (http://www.eiffel.com).
  1307.  
  1308. ----------
  1309.  
  1310. L08)   Why doesn't Eiffel allow function overloading?
  1311.  
  1312. In Eiffel, no two features of a class may have the same identifier,
  1313. regardless of their respective signatures.  This prevents the use of
  1314. function overloading ("multiple polymorphism"), a common programming
  1315. technique in languages like C++.
  1316.  
  1317. Eiffel is designed to be minimal: it includes exactly the features
  1318. that its designer considered necessary, and nothing else.
  1319.  
  1320. Because Eiffel already supports (single) polymorphism through its
  1321. inheritance system, the only positive thing that function overloading
  1322. buys you is reducing the number of feature names you have to learn.
  1323. This is at the expense of reducing the ability of the compiler to trap
  1324. mistakes (often type errors).
  1325.  
  1326. Readability is also enhanced when overloading is not possible. With
  1327. overloading you would need to consider the type of the arguments as
  1328. well as the type of the target before you can work out which feature
  1329. is called. With multiple inheritance and dynamic binding this is
  1330. awkward for a compiler and error-prone for a human. There is no
  1331. intuitive rule which could be used to disambiguate routine calls where
  1332. there is no "nearest" routine.
  1333.  
  1334. However, in Eiffel it's easy to write one routine with arguments of
  1335. the most general applicable type, then use the assignment attempt
  1336. operator to carry out the appropriate operation according to the
  1337. run-time type of the arguments (thereby explicitly programming the
  1338. disambiguation "rules").
  1339.  
  1340. Having said that, the lack of multiple polymorphism does force us to
  1341. write some common mathematical operations (e.g. matrix math) in an
  1342. awkward way, and forces arithmetic expressions to be treated specially
  1343. (the "arithmetic balancing rule", ETL p385). But no-one has come up
  1344. with a solution which is so simple, elegant and useful that it
  1345. improves the quality of Eiffel as a whole.
  1346.  
  1347. ----------
  1348.  
  1349. L09)   Why are there no procedural types in Eiffel?
  1350.  
  1351. The notion of allowing a routine to be passed as an argument to a
  1352. routine is in many people's view incompatible with the OO method. The
  1353. definition of object-orientation implies that every operation belongs
  1354. to an object type, so one does not manipulate routines just by
  1355. themselves.
  1356.  
  1357. A possible technique when one feels the need to use a routine argument
  1358. is to write a class and include the routine in it. Then (rather than
  1359. passing a routine argument) pass an object - an instance of this class
  1360. - to which the routine can then be applied. This is a more flexible
  1361. approach in the long term. For example, you may later add an "undo"
  1362. routine to your routine - containing class, or an attribute such as
  1363. "time of last execution".
  1364.  
  1365. ----------
  1366.  
  1367. L10)   Why are there no class attributes in Eiffel?
  1368.  
  1369. In Eiffel, the "once" function provides greater functionality in a
  1370. more disciplined way. The body of a "once" function is executed once
  1371. only, when it is first called. Thereafter, the "once" function returns
  1372. the same Result without re-executing its body.
  1373.  
  1374. The "once" function can therefore be used to implement a shared
  1375. attribute of reference type (initialized on its first use).
  1376.  
  1377. A "once" function can be included in a mixin class. The shared
  1378. attribute returned by that once function is then available to all
  1379. instances of classes which inherit from the mixin class.
  1380.  
  1381. ----------
  1382.  
  1383. L11)   How can I call the parent-class version of a redefined routine?
  1384.  
  1385. When an inherited routine is redefined in a child class, is there a
  1386. way for the redefined routine to call the version in the parent class?
  1387.  
  1388. 1) If you are responsible for the design of the parent class, you may
  1389.    anticipate such a need. You may provide multiple versions of the
  1390.    same routine body, with some versions frozen (not redefinable):
  1391.  
  1392.    class PARENT
  1393.    feature foo, frozen parent_foo is
  1394.       do
  1395.          ...
  1396.       end
  1397.    end
  1398.  
  1399.    class CHILD
  1400.    inherit
  1401.       PARENT
  1402.          redefine foo
  1403.       end
  1404.    feature foo is
  1405.       do
  1406.          parent_foo
  1407.          ...
  1408.       end
  1409.    end
  1410.  
  1411. 2) Otherwise, you use repeated inheritance to get two versions of
  1412.    'foo', and redefine one of them:
  1413.  
  1414.    class PARENT
  1415.    feature foo is
  1416.       do
  1417.          ...
  1418.       end
  1419.    end
  1420.  
  1421.    class CHILD
  1422.    inherit
  1423.       PARENT
  1424.          rename foo as parent_foo
  1425.       end
  1426.       PARENT
  1427.          redefine foo
  1428.          select foo  -- (in case of dynamic binding)
  1429.       end
  1430.    feature
  1431.       foo is
  1432.          do
  1433.             parent_foo
  1434.             ...
  1435.          end
  1436.    end
  1437.  
  1438. ----------
  1439.  
  1440. L12)   Where can I find a comparison between Eiffel and C++?
  1441.  
  1442. In Richard Wiener's book "Software Development Using Eiffel: There can
  1443. be life after C++" (Prentice-Hall, ISBN 0-13-100686-X).
  1444.  
  1445. ----------
  1446.  
  1447. L13)   Are there any destructors in Eiffel?
  1448.  
  1449. Eiffel objects are garbage-collected, so that there is no need for the
  1450. software developer to worry about whether, how and when to "destruct"
  1451. or "free" them in the software text.
  1452.  
  1453. Some implementations offer a "free" procedure for programmers who
  1454. absolutely want to remove an object manually. Such a procedure is "use
  1455. at your own risk" and is not needed in normal Eiffel development.
  1456.  
  1457. Coming back to normal usage, the need may arise to ensure that certain
  1458. operations will automatically take place whenever the garbage
  1459. collector reclaims an object. For example if an Eiffel object
  1460. describing a file becomes unreachable and hence is eventually
  1461. garbage-collected, you may want to ensure that the physical file will
  1462. be closed at that time. Some implementations of Eiffel provide a
  1463. mechanism for that purpose: procedure 'dispose' from the Kernel
  1464. Library class MEMORY.
  1465.  
  1466. Whenever the garbage collector collects an object, it calls 'dispose'
  1467. on that object. The procedure does nothing by default (so that a smart
  1468. GC will of course avoid executing any actual call). But any class may
  1469. inherit from MEMORY and redefine 'dispose' to perform appropriate
  1470. actions, such as closing a file. Such actions are sometimes called
  1471. "finalization". This technique achieves it conveniently.
  1472.  
  1473. Because there is no guarantee as to the order in which the garbage
  1474. collector will reclaim objects that have become unreachable, safe
  1475. redefinitions of 'dispose' should only act on external resources such
  1476. as file descriptors, database elements, window system resources etc,
  1477. not on Eiffel object structures themselves.
  1478.